Gestión de equipo - Sprint 1
Universidad de Sevilla
Escuela Técnica Superior de Ingeniería Informática
Grado en Ingeniería Informática – Ingeniería del Software
Curso: 2024 – 2025
Fecha: 23/02/2025
Versión: v1.1
Grupo de prácticas: G1
Nombre del grupo de prácticas: ISPP - Grupo 1 - Holos
- María del Mar Ávila Maqueda
- Joaquín González Ganfornina
- Nerea Jiménez Adorna
- Juan del Junco Obregón
- Miguel Ángel Gómez Vela
- Juan Antonio Moreno Moguel
- María del Carmen Barrera Garrancho
- Daniel Guedes Preciados
- Julia Virginia Ángeles Burgos
- Javier Muñoz Romero
- Juan Núñez Sánchez
- Nicolás Pérez Gómez
- Francisco Pérez Lázaro
- Celia Aguilera Camino
- Gabriel María Vacaro Goytía
- Ignacio Warleta Murcia
- José María Portela Huerta
Responsables:
| Miembro | Responsabilidad |
|---|---|
| José María Portela | Redactor |
| María del Mar Ávila | Revisora |
Repositorio: GitHub - Holos-INC
Control de Versiones
| Fecha | Versión | Descripción | Autor |
|---|---|---|---|
| 23/02/2025 | v1.0 | Creación de documento | José María Portela |
| 13/03/2025 | v1.1 | Modificación Portada | María del Mar Ávila |
Índice de Contenidos
1. Introducción
En el contexto del proyecto de esta asignatura, hemos necesitado fijar unos protocolos para la gestión del equipo, como puede ser la medición del rendimiento del equipo de manera objetiva, así como las comunicaciones y el ratio de respuesta de estas. Además, también consideramos de vital importancia establecer las responsabilidades que cada uno de nosotros debemos tener, junto a una Tabla RACI. Con ayuda de esta tabla sabremos mejor cuál es nuestra labor dentro del ciclo de vida de cada tarea. Para terminar, usaremos una definición de hecho que nos será de vital importancia para terminar el ciclo de vida de una tarea.
2. Rendimiento del equipo
En esta sección hablaremos de los aspectos clave relacionados con el rendimiento del equipo. Abordaremos temas cómo las herramientas por las cuales evaluaremos el rendimiento, además de qué medidas tomaremos que consideremos importantes. Y, terminando por un ratio de respuesta a mensajes, el cuál nos brindará un conocimiento mejor de qué compañeros están más atentos a las tareas, además de que se visualizará los que tengan más iniciativa.
Además, es de vital importancia avisar con la mayor brevedad de que el integrante del grupo no puede realizar una tarea en una fecha, para poder realizar reasignaciones, compensando horarios más adelante en el trabajo.
2.1 Herramientas para medir el rendimiento
Para el rendimiento, usaremos tecnologías como Clockify, para medir el tiempo usado por tarea. Para el seguimiento de las tareas, usaremos GitHub Projects, con el uso de las estimaciones de las tareas. Codacy para evaluar el código.
2.2 Mediciones a tomar
Se tomarán las siguientes métricas, para evaluar el avance del proyecto:
-
Lo añadido a este documento: Team Performance Model
-
Rendimiento de las tareas: Dividir los puntos de usuario (estimación) entre las horas dedicadas a esa tarea, para conseguir un porcentaje de rendimiento. Cuanto mayor sea este porcentaje, mejor ha realizado la persona el trabajo.
-
Ratio de respuesta a mensajes: Número de veces contestadas / número de solicitudes de información mandadas.
2.2.1 Ratio de respuesta
Esta sección sirve para detallar el ratio de respuesta descrito anteriormente. Se usará un excel en el que se irá agregando las solicitudes de reunión, formularios e información sobre cómo avanza el proyecto. En caso de no haber habido problemas por causas mayores, como la muerte de un familiar, accidente o similar, se contará como no respondido si no se contestara a una encuesta, when2meet (para reuniones), o solicitud de estado del proyecto en las siguientes 8 horas a la solicitud de estos. En estas 8 horas, se encuentran incluidas solo las horas desde las 7:00 hasta las 23:00.
También cuenta como respuesta el decir no sé, o no podré asistir a la reunión. Pero que al menos se sepa de que el integrante del grupo ha visto el mensaje, y comente su situación.
Por ejemplo, si el PM hace una solicitud de estado del proyecto a las 21:00, seguiría contando como respuesta un mensaje al día siguiente a las 11:00. Habrían pasado 6 horas.
Con esta medida aseguramos que nos comuniquemos más y mejor.
3. Responsabilidades del equipo
La responsabilidades siguientes del grupo son de vital importancia, siendo cada persona la que vigile que su tarea se lleva con éxito. Para destacar y aclarar responsabilidades, las detallaremos después de pasar el siguiente listado:
- CELIA AGUILERA CAMINO: Responsable de Redes Sociales.
- JULIA VIRGINIA ANGELES BURGOS: Coordinadora de Frontend.
- MARIA DEL MAR AVILA MAQUEDA: Responsable del aseguramiento de comprobar que cumplimos los criterios para aprobar.
- MARIA DEL CARMEN BARRERA GARRANCHO: Jefe de costes de la aplicación.
- JUAN DEL JUNCO OBREGON: Secretario, es decir, responsable de tomar acta y recoger el feedback.
- MIGUEL ANGEL GOMEZ VELA: Responsable del uso de IA, y de la inclusión de esta en los documentos.
- JOAQUIN GONZALEZ GANFORNINA: Responsable de revisar costes.
- DANIEL GUEDES PRECIADOS: Responsable de subir información en la base de conocimiento común.
- NEREA JIMENEZ ADORNA: Responsable de usuarios pilotos.
- JUAN ANTONIO MORENO MOGUEL: Coordinador de Backend. Responsable de que se recojan las métricas del equipo.
- JAVIER MUÑOZ ROMERO: Responsable de calidad software.
- JUAN NUÑEZ SANCHEZ: Responsable de calidad de documentación.
- NICOLAS PEREZ GOMEZ: Responsable de revisar los competidores.
- FRANCISCO PEREZ LAZARO: Responsable de imagen, manteniendo la homogeneidad en Frontend, Landing Page y Presentaciones.
- JOSE MARIA PORTELA HUERTA: Project Manager, responsable de gestión de problemas entre miembros del grupo, y de asignar, organizar y crear tareas.
- GABRIEL MARÍA VACARO GOYTIA: Secretario, es decir, responsable de tomar acta y recoger el feedback. Y responsable del docusaurus del grupo.
- IGNACIO WARLETA MURCIA: Responsable de que el equipo acate el feedback.
El aseguramiento de los criterios es la revisión de todos los documentos y todos los requisitos detallados por los profesores, además de informar a las debidas personas a las que les influya estos requisitos. Ser responsable del uso de IA implica también solicitar a los compañeros los links y descripciones para incluirlos en la documentación pertinente, así como ir solicitando por los debidos grupos esta información para poder completarla adecuadamente. Ser responsable de la base de conocimiento común implica la redacción y subida del contenido correspondiente al feedback que se da de manera grupal a otros grupos, al nuestro y las tareas mandadas por los profesores; se diferencia de recoger el feedback en que debe subirse a un docusaurus distinto (enlace a dicho docusaurus). Responsable de usuarios pilotos incluye no solo buscar y pasar formularios a estos, sino también asegurarse de que consigue feedback de estos, bien organizando calendarios para quedar con ellos o gestionar que alguien quede con ellos, o pasándoles plantillas. Ser responsable de calidad implica comprobar que se siguen los criterios de aceptación incluidos en la documentación, así como las políticas de commits, issues, comprobar que codacy trabaje bien, etc. Ser responsable de revisar los competidores es revisar que toda la documentación de estos es correcta, así como usar herramientas para comprobar que no sale ninguno nuevo directo, y en caso de que salga avisar a los compañeros y planear una estrategia de diferenciación. Y por último, ser responsable de que se acate el feedback implica revisar el feedback durante el proyecto y comprobar que se está llevando a cabo, según dicen los profesores.
3.1. Tabla RACI
En las distintas tareas, un miembro puede tomar distintos roles, aunque solo uno para dicha tarea. Según la tarea y el rol, tendrá un papel u otro en esta:
- Responsable: Persona que es asignada en una tarea, y que debe realizarla dentro del plazo dado en el proyecto. Una vez terminada la tarea, la incluirá en In Review, y avisará a los aceptadores de esta para que la revisen
- Aceptador: Persona que es responsable de revisar la tarea. Primero creará una subissue de la tarea a revisar, siguiendo el siguiente formato:
<Nombre completo de la tarea junto al id de este>'/REVN, siendo REVN las revisiones que se hayan tenido que tomar, como REV1 para la primera, REV2 para la segunda, y así sucesivamente. - Consultado: Persona a la que se puede consultar información pertinente a la tarea.
- Informado: Persona a la que se debe informar del estado de la tarea, diferenciándose del anterior en que este rol no tiene por que recibir feedback, solo saber el estado de la tarea o problemas que hayan sucedido.
| Project Manager | Eq. Desarrollo | Eq. Tester | Eq. QA (Calidad) | Eq. Diseño | Eq. Documentación | |
|---|---|---|---|---|---|---|
| Código | C,I | R | A | I | C | C |
| Documentación | C,I | C | I | A | C | R |
| Despliegue y mantenimiento | A,C,I | I | R | A | I | C |
| Presentación | R | I | I | A,C | R | I |
| Pruebas | C,I | R | R,A | A | C | I |
| Diseño Frontend | I | R | A | A | R | C |
| Licitación de requisitos | R | C,I | C,I | A,I | C,I | I |
| Criterio de suspenso | R | I | A,C,I | A,C,I | I | I |
4. Ciclo de vida de una tarea
Para el ciclo de vida de una tarea, nos basaremos en la siguiente imagen:
En ella, se puede visualizar claramente el proceso por el que debe pasar una tarea, y los pasos que deben hacer los integrantes del equipo de cara a las responsabilidades de Responsable y Aprobador. También se indica cuando ha de informar a las personas Responsable e Informado, siendo este último caso más habitual si se viera necesario o conveniente. Para el rol de Consultado, este se puede solicitar en cualquier momento durante el desarrollo de la tarea.
4.1 Definición de hecho
La definición de hecho, tanto de un documento como de una tarea de código se desarrolla en la imagen anterior, siendo una tarea finalizada correctamente una vez haya cumplido la definición de esta tarea, haya sido revisada por una persona que no participase en la creación del documento y tenga la profundidad y cantidad necesaria de información.
Esta tarea podría reabrirse en caso de que el PM viera que falta profundidad o información relevante en la documentación o código.
5. Anexo
Destacar que este documento no es definitivo en esta versión, está a la espera de la visualización del equipo y respectiva votación, que quedará cerrada el lunes 24 de febrero a las 22:00. Después de esto, se editará el documento a una primera versión definitiva.